====== IOSERDES: Test runs previous to processing ======

\\
\\
\\
=====  About the plots =====
----

The following are delta-count plots. 
Time goes from top to bottom, and each column corresponds to a (32-bit) error counter (see abscissa labels). A darker blue corresponds to a higher delta-count value. Note that it has enough resolution, just click on it and zoom-in for a detailed view. \\
Color red represents any negative value (e.g., the user in the GUI commanding the reset of the counters). Color cyan represents any value greater than a large threshold (a value not reachable in a correctly-working test).\\
These are mostly CRAM hit patterns, so we should expect the counters running always at the same (1/2 free-running) speed, with variations only corresponding to the variance on the counters values' sampling time (before being sent through serial port to the GUI/log). 


===== Clock network for the IOSERDES test ===== 
----

As a reference for the subsequent analysis, here's a preliminary diagram of the clocking network in the DUT, where we also see a grouping factor of 3 outputs per input, and nine outputs per bank. 
The master clock is provided from the FuncMon FPGA.\\
Looking at the topology, it seems unlikely that we can have an out-of-step condition caused by an SET transient seen either by the ISERDES or OSERDES clock, only. \\
We can probably have an out-of-step condition due to an upset in the divider inside each BUFR buffer; this would affect an entire bank. \\ 



{{ data_analysis:v7-dynamic:201703-tamu:ioserdes:ioserdes_clock_nets.jpg }}


===== Summary of strange features =====
----

In the following two delta-count plots we have all the IOSERDES test runs, both for low- and high-speed tests.\\
Note that we have some anomalous delta-count (average) values of counters, with cells having different (average) levels of blue color darkness.\\
For example, the stronger blue color zones correspond to a behavior similar to "case 2" described in the [[data_analysis:v7-dynamic:201703-tamu:iob:hstl| (201703-TAMU) HSTL analysis section ]]. 
In that section, we noted that both HSTL and LVCMOS(3V3) tests showed events of considerable duration with  delta-counts larger than expected, in a factor of 2. 
Here in the IOSERDES tests we just checked a few events, **notably having accumulated delta-count  factors of 2, 1.5 and 0.5** (besides the reference factor of 1).

==== - Example 1 ====  

These cases appear in run 80, a low-speed test. 
It's a particularly interesting example, due to a superposition of effects.  

The following sequence of events start near the red dot marking in the plot. 

  - **[time 07:38:30.85]** We have the onset of an event (cells with darker blue levels) in Counter10 error counter, with **a factor of "1.5x"** in the accumulated delta-count values. This seems to be persistent at least up to time ~ 07:40:01, eventually in superposition to the following events. \\
  - **[time 07:38:35.53]** Here we have the onset of an event with the range of counters Counter[17:0] all running together (note that the range Counter[26:18] was already in upset from a previous time), masking-out the observability of the previous effect that we assume is still affecting Counter10. This corresponds to the onset of two banks in upset, according to Bob's documentation, covering error counter ranges: Counter[17:9] and Counter[8:0] . In this case, the counters are reporting the typical amount of delta-counts we find in the non-SERDES IOB tests; i.e., in average the 50% of the time in error, obtained when comparing the checkerboard pattern with a "stuck" signal, according to the appropriate test frequency. That typical accumulated delta-count is our reference, say a **"1x" factor**. This event seems to disappear (scrubbed-out or maybe transient) after an interval of little less than 2 seconds and, after that, we see that visibility is recovered on the "1.5x" high-speed event in Counter10.    
  - **[time 07:38:58]** Another event with similar "bank in upset" behavior, "1x" factor, for the bank corresponding to the range of counters Counter[17:9]. The duration of this condition is less than 5 seconds.  \\
  - **[time 07:39:25]** Again, an event similar to the previous one. 
  - **[time 07:39:54.20]** From the onset of this event and as a result of the superposition, Counter10 is masking-out the underlying fault mode for the range of counters Counter[17:9], the latter fault having a **"0.5x" factor** for the accumulated delta-count. That is, visibility is sustained on the Counter10 ("1.5x" factor) fault mode. 
  - **[time ]** Finally, we see what is probably a device-wide fault mode, having a "1x" factor.

From the previous observed events, we can infer the following. 
  * Points 2, 3 and 4, with "1x" factor, seems to correspond to the classical bank fault mode, having the outputs stuck in a given logic value.   
  * Point 1, with "1.5x" factor, seems to correspond to a fault mode <hi>**[TBD]**</hi> on an OSERDESE2 block associated to an IOB for a given output, having in average 3 out of 4 bits affected. 
  * In Point 5, the bank in upset with "0.5x" factor, seems to appear due to a fault mode having in average 1 out of 4 bits affected. <hi> This is a new **[TBD]** apparently bank-wide upset mode (not having the outputs stuck in a given value that would give a "1x" factor). Moreover, it's also strange that Counter10 keeps running with a "1.5x" factor, not enhancing (to a lower factor) nor worsening (to a "2x" factor) its accumulated delta count values.</hi>
==== - Example 2 ==== 

These cases appear in run 84, a high-speed test. 
  * Time: 19:47:23.4878, Counter: 54, **factor: 1.5**;
  * Time: 19:47:36.425,  Counter: 26, **factor: 1.5**;  
  * Time: 19:53:37.26,  
    * Counter: 4, **factor: 1**,  
    * Counter: 10, **factor: 2** (marked in red), 
    * Counter: 15, **factor: 1.5**;
  * Time: 19:53:55.39,  
    * Counter: 4, **factor: 1**,  
    * Counter: 10, **factor: 1.5**, 
    * Counter: 22, **factor: 0.5** (marked in orange);


\\
===== IOSERDES: Summary of LO and HI speed runs =====
----

\\
** The following plot corresponds to all "low-speed" IOSERDES test runs: ** \\
(the only LO speed run is actually run 80)\\
{{ data_analysis:v7-dynamic:201703-tamu:ioserdes:testruniob--serdes--lo_speed--non-packaged_counters--previous_to_processing_-edited.png }}


** The following plot corresponds to all "high-speed" IOSERDES test runs: ** \\
{{ data_analysis:v7-dynamic:201703-tamu:ioserdes:testruniob--serdes--hi_speed--non-packaged_counters--previous_to_processing.png }}


\\
===== IOSERDES: Individual runs =====
----

The following are the individual test runs, previous to any processing. 
The test run numbering corresponds to the assignment done by the Python script; the correspondence table is in the modified "facility spreadsheet", file 'tests_facility.csv'.


\\
** The following plot corresponds to test run 80 (LO): ** \\
NOTE: There's a problem (range of colors) with this plot, we will update it after the next iteration of plotting all runs. Meanwhile, please check the previous "all low-speed tests" plot, as it coincides with run 80.\\
{{ data_analysis:v7-dynamic:201703-tamu:ioserdes:testrun80--preliminary.png }}

\\
** The following plot corresponds to test run 84 (HI): ** \\
{{ data_analysis:v7-dynamic:201703-tamu:ioserdes:testrun84--preliminary_-edited.png }}

\\
** The following plot corresponds to test run 85 (HI): ** \\
{{ data_analysis:v7-dynamic:201703-tamu:ioserdes:testrun85--preliminary.png }}

\\
** The following plot corresponds to test run 104 (HI): ** \\
{{ data_analysis:v7-dynamic:201703-tamu:ioserdes:testrun104--preliminary.png }}

\\
** The following plot corresponds to test run 106 (HI): ** \\
{{ data_analysis:v7-dynamic:201703-tamu:ioserdes:testrun106--preliminary.png }}

\\
** The following plot corresponds to test run 107 (HI): ** \\
{{ data_analysis:v7-dynamic:201703-tamu:ioserdes:testrun107--preliminary.png }}

\\
** The following plot corresponds to test run 108 (HI): ** \\
{{ data_analysis:v7-dynamic:201703-tamu:ioserdes:testrun108--preliminary.png }}

